home *** CD-ROM | disk | FTP | other *** search
-
- Network Working Group D.L. Mills
- Request for Comments: 996 University of Delaware
- February 1987
-
-
- Statistics Server
-
- STATUS OF THIS MEMO
-
- This RFC specifies a standard for the ARPA Internet community. Hosts
- and gateways on the DARPA Internet that choose to implement a remote
- statistics monitoring facility may use this protocol to send
- statistics data upon request to a monitoring center or debugging
- host. Distribution of this memo is unlimited.
-
- DISCUSSION
-
- Many host and gateway implementations include a facility which
- records traffic statistics, such as packet counters, error counters
- and significant event counters for debugging and performance
- evluation. Simple data-access and formatting programs can be used to
- display these statistics along with the status of connections, etc.
- Several operating systems, including the various Unix systems and
- Fuzzball systems, already provide extensive facilities to capture and
- display these data for local users and/or operators.
-
- In many instances it is highly useful to observe statistics data on
- remote hosts and gateways from a monitoring center or debugging host.
- Indeed, several protocols have been implemented and used expressly
- for this purpose [1-6]. In many cases the data can be retrieved using
- conventional services such as remote login or even file transfer.
- However, use of these heavyweight mechanisms is awkward and intrusive
- if conducted on a regular, frequent basis and may involve substantial
- intrusion in the operating system if retrofitted to existing systems.
-
- The Statistics Server (STATSRV) protocol is intended as a lightweight
- mechanism similar in spirit to NETSTAT [7] and complementary to it.
- STATSRV is designed to capture statistics data with minimal intrusion
- on existing systems or networks. It is intended for use with existing
- hosts and gateways primarily for casual monitoring and debugging
- purposes. It is not intended as a full-function monitoring protocol
- [1,5,6] providing detailed, standardized reports suitable for machine
- analysis, for example, but could be useful in exploratory development
- leading to enduring systems of this type.
-
- The STATSRV model is based on the native host command language used
- for statistics monitoring and display. The client sends a null-
- terminated ASCII command to the server, which then responds with a
- null-terminated ASCII response suitable for a printer or CRT display.
- Although in principle STATSRV could be used over TCP, it is less
- intrusive and more efficient to use it over UDP. In the case of UDP,
-
-
-
- D. L. Mills [Page 1]
-
- RFC 996 February 1987
-
-
- commands and responses must fit into a single 576-octet IP datagram.
- In both UDP and TCP the assigned port number is 133 (decimal).
-
- As is conventional in other lightweight services of this type
- (NETSTAT, FINGER, etc.), there is no provision for access control or
- authentication in STATSRV. If necessary, each command could include a
- password or other mechanism to discourage casual abuse.
-
- EXAMPLE
-
- The Fuzzball system includes many local commands to display internal
- data structures, including one that produces the following billboard
- for each network device, in this case "dm0" on host "udel2.udel.edu":
-
- Process type: 000027 options: 040000
- Subnet: DMV status: 376 hello: 15 timeout: 2000
- Foreign address: [192.5.39.87] max size: 576
- Input packets 3645 Output packets 3690
- bad format 0 ICMP msgs 0
- bad checksum 0 Input errors 0
- returned 0 Output errors 0
- dropped 2 No buffer 0
- HELLO msgs 2286 Preempted 0
-
- The same billboard is returned as a null-terminated ASCII string in a
- UDP datagram by sending the null-terminated ASCII command "dm0" in a
- UDP datagram to the host. Similar billboards can be produced for most
- processes in the system. Unix programs and shell scripts have been
- built which send commands like these to selected hosts on a periodic
- basis in order to construct a simple, ad-hoc monitoring facility.
-
- REFERENCES
-
- [1] Flood Page, D.,"Gateway Monitoring Protocol", DARPA Network
- Working Group Report IEN-131, Bolt Beranek and Newman, February
- 1980.
-
- [2] Flood Page, D., "The CMCC Terminal Process", DARPA Network
- Working Group Report IEN-132, Bolt Beranek and Newman, February
- 1980.
-
- [3] Flood Page, D., "CMCC Performance Measurement Message Formats",
- DARPA Network Working Group Report IEN-157, Bolt Beranek and
- Newman, September 1980.
-
- [4] Jones, R.G., " A Proposal for Simple Measurement Support for
- Users", DARPA Network Working Group Report IEN-161, University
- College London, November 1980.
-
-
-
-
-
-
- D. L. Mills [Page 2]
-
- RFC 996 February 1987
-
-
- [5] Littauer, B.M., A.J. Huang and R.M. Hinden," A Host Monitoring
- Protocol", DARPA Network Working Group Report IEN-197, Bolt
- Beranek and Newman, September 1981.
-
- [6] Hinden, R.M.," A Host Monitoring Protocol", DARPA Network
- Working Group Report RFC-869, BBN Communications Corporation,
- December 1983.
-
- [7] Reynolds, J.K., and J. Postel, "Assigned Numbers", DARPA Network
- Working Group Report RFC-990, USC Information Sciences
- Institute, November 1986.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- D. L. Mills [Page 3]
-
-